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1 Introduction 


1.1 Background 


The design and implementation of programming languages has come a 
long way since the use of machine code for directly programming com- 
puters. These improvements have allowed the development of software 
systems larger than ever before, without sacrificing on correctness or ro- 
bustness. Type systems are a vital part of programming language design 
that have allowed computer programmers to meet the demands for cor- 
rect and properly functional programs. One definition of type systems for 
programming languages would be: “A type system is a tractable syntactic 
method for proving the absence of certain program behaviors by classify- 
ing phrases according to the kinds of values they compute” (Pierce 1). In 
other words, type systems assign a type to different expressions and con- 
structs in a programming language based on properties such as the values 
they compute. The type system can then reason about the behavior of a 
program by methodically looking at how different types interact with each 
other, and then based on the rules of the type system, decide whether the 
program is well-behaved (it adheres to the rules of the system) or not. As 
an example, the following Java program fails to compile due to an error in 
the type system: 


Listing 1: Ill-behaved Java program 


int x = 1; 
String y = "2"; 
// error: bad operand types for binary operator ‘/’ 


System.out.println(x / y); 


While the error is obvious in this example, in larger codebases it is not 
always easy for the programmer to notice small errors. This is where the 
type checker comes in. The job of a type checker (which is usually included 


in the compiler itself) is to ensure that the source code adheres to the rules 


of the type system. 


1.2 Type Inference 


Due to its vast benefits, most compiled languages offer some form of type 
checking in order to aid the development of software. However, type 
checking has certain drawbacks that make it an inconvenient feature for 
programmers in certain situations. One major drawback is that sound 
type checking requires that all expressions appearing in the source code 
must belong to a certain type. In order to satisfy this requirement, the 
programmer has to manually annotate every expression with its type, 
such as in the first two lines of Listing 1. This can often lead to overly 
verbose code and hinder productivity. For example, one criticism of Java 
that influenced the development of the Kotlin programming language was 


its verbosity, which in turn leads to poor readability (Breslav). 


The solution to this is to have the compiler analyze a program to automat- 
ically infer the types of expressions appearing in it. This is known as type 
inference (Krishnamurthi). Type inference eliminates the need for pro- 
grammers to explicitly annotate expressions. Moreover, type inference can 
be integrated within tools such as Integrated Development Environments 
(IDEs) to further aid development by, for example, providing documenta- 
tion or catching errors before executing the program. Due to its close ties 
with the type system, powerful type inference is often also indicative of a 


powerful type system. 


13 Type Inference for OOP Languages 


Languages belonging to the functional programming (FP) paradigm, such 


as Standard ML or Haskell, have included type inference as a feature for 


a long time. However, it has been largely absent from most common 
object-oriented programming (OOP) languages for quite some time, and 
has only recently started to become a common feature of some (Melo). This 
is because the strong type systems of FP languages lend themselves well to 
type inference, whereas for OOP languages certain features (in particular, 
polymorphism) make type inference a much more difficult task. 


Given the benefits of type inference and type checking, and considering 
the popularity of OOP languages, the question of to what extent type 
inference is possible for statically typed polymorphic OOP languages is an 


interesting one which I was interested to study further. 


Note that because OOP is merely a paradigm, languages are free to choose 
how closely they adhere to OOP principles. As such, this essay does not 
focus on any particular language. Rather, it develops the minimal lambda 
calculus (A-calculus) for reasoning about programming languages, and 
later extends it with features of polymorphism common (but not strictly 
unique) to OOP languages. This is then used to explore and understand 


barriers to type inference in OOP languages. 


2 The Lambda Calculus 


2.1 Untyped A-calculus 


The untyped A-calculus (Church, Introduction to Mathematical Logic; The 
Calculi of Lambda-Conversion) is a minimal yet Turing-complete program- 
ming language that can be used to model computation, using only function 
abstraction and application. Its usefulness comes from the fact that it can 
be considered not only as a programming language, but also a formal sys- 
tem for making and proving logical statements (Pierce). It is an important 
tool in programming language design, and will also help us in exploring 
type inference for OOP languages. In order to illustrate its use, we will be- 
gin with the untyped A-calculus and extend it to obtain the Simply-Iyped 
Lambda Calculus (STLC). 


The syntax of the untyped A-calculus is as follows, using Backus-Naur 


form (BNF) notation (see Appendix A for a summary of this notation): 


Ciis terms: 
x variable 
| Ax.t abstraction 
| application 

y f= values: 
AN abstraction value 


As shown above, the syntax comprises of just three terms. Variables, such 
as x are terms; abstraction of a variable x over a term t (this is akin to 
a function definition with one parameter x, which returns t); and appli- 
cation of a term to another term t (this is akin to function application). 
The only “value” in A-calculus (that is, an expression that cannot be eval- 
uated further) is abstraction itself. Note that unlike other programming 
languages, A-calculus does not have any built-in constants or primitives 


such as numbers or conditionals. 


“Computation” is reflected by evaluating the terms of an expression to 
obtain a simpler expression. The primary evaluation rule in A-calculus is 
an evaluation of function application. If an expression contains a function 
application of some term tı to a lambda abstraction tz, then this can be 
evaluated by replacing all occurrences of the abstraction variable in tz with 
tı. This substitution is written as [x +> t1]t7, which reads as “replace all 
free occurrences of x in tz by tı” (Pierce). For example, the term (1x.x)y 
consists of an application of the variable y to the function Ax.x. This 
function simply returns the argument provided, and so the term (Ax.x)y 


would evaluate to just y. 


This evaluation rule can be more formally expressed using inference rules 
(see Appendix A for a summary of this notation): 


tı t2 Vi ta 
tits tz — t’? 
LA ——————— EApp2: —————————— 
tı t2 —>t ıtz2 vı tz — vı t’2 


E-AppAbs: (Ax.t12)V2 — [x hb v2]ti2 


The notation t —> t’ means that the term t can be evaluated to t’. 
Essentially, “—>” represents a ‘computation’ step. Here, the rule E-App1 
tells us that the term t; tz, where tı — t’, evaluates to t’1 tz. Although 
it appears to be obvious, it is important because it specifies the order of 
computation: before the function application t; tz can be performed, the 


term tı needs to be fully evaluated. 


Similarly, the rule E-App2 tells us that the expression vı tz, where tz — 
t’2, evaluates to vı t’2. Here, the (meta-)variable vı stands for a value 
rather than a term, meaning that it cannot be evaluated any further. In 
other words, before the function application vı tz can be performed, the 
term t needs to be fully evaluated. Finally, the rule E-AppAbs tells us how 


to perform the function application, which is to perform a substitution. 


2.2 Simply-Typed Lambda Calculus 


A-calculus can be extended with types to obtain the STLC. To demonstrate 
typing, we will add the boolean type to it. First, we extend the syntax: 


t iis terms: 
(previous terms) 


| true true 
| false false 
| Ax: T.t lambda abstraction 
Vis values: 


(previous values) 


| true true value 
| false false value 
Tits types: 
CT function type 
| Bool boolean type 


We have added the two new boolean terms, true and false, both of which 
are values as well. Aside from that, the lambda abstraction term is also 
different now; rather than simply x, the argument is now written x : t. The 
new symbol t ranges over the types available in the STLC: the function 
type t — T’, and the newly-added Bool type. An example of a concrete 
function type would be Bool — Bool. An example of a value belonging to 
this type would be (Ax : Bool.x). 


We can now use typing rules to define the behavior of our new terms and 


types (see Appendix A for a summary of this notation): 


¿TEL 
T-True: — T-False: aS == TVar: = ASA 
+ true : Bool + false : Bool Terx:7T 


Terti:T>7 
TIOXTEtiT Teto:7 
T-Abs: ————————— T-App: — 
LEAR >T Tt tit: 7’ 
The first three rules are straightforward: true and false are of type Bool, 
and if x : t is in the context T, then x is of type t under that context. 
The rule T-Abs describes typing for lambda abstractions: the abstraction 
variable x : t is added to the context T (because the variable might appear 
in the term t), and given that the term t is of type 7”, then we can conclude 
that a lambda abstraction of the form (Ax : t.t) is of type tT — T’ (since t is 
the return value of the abstraction). T-App states that a term of type t — 


t’ can be applied to a term of type T, resulting in a term of type 7’. 


In this manner, by extending the syntax and grammar to add new terms 
and types, and defining typing rules for the behavior of those terms and 
types, we can extend the STLC to add new features to it. Before extending 
it with OOP features, we will first consider how type inference may be 


performed on the STLC developed so far. 


2.3 Type Inference as Constraint Satisfaction 


One common technique for performing type inference on the STLC (and 
FP languages derived from STLC) is to model it as a Constraint Satisfaction 
Problem. A constraint between two types t and 7” (denoted t ~ 7”) simply 
states that the two types must be unified, or in other words, they should 
be equal to each other. A constraint set (usually denoted C) is a list of such 
constraints for a given program (where type annotations may be partially 
or completely absent). A unification function is one which generates a 
substitution that satisfies all constraints in C (Suidman, “Introduction to 
Type Systems: Type Inference”). In other words, it finds a solution to the 


constraint satisfaction problem. 


For example, consider the following function written without type anno- 


tations (in a common FP language): 


Listing 2: Constraint-based Inference 


The job of the inference algorithm is to infer the type of the variable x and 
the function f. First, because we do not yet know the types of these terms, 
we will assign type variables to them, so that x : Tp and f : 71. Next, we 
analyze the body of the function, which consists of a single operation, x + 
x. We assign this expression a type variable as well, so that (x + x) : 7. 
Since f is a function whose argument is x and return value is (x + x), we can 
generate the constraint T1 ~ (To — T2). We know that the operator ‘+’ takes 
two values of type Int, so we can generate the constraint To ~ Int (in fact, 
we would generate two constraints for both the left-hand and right-hand 
side of the operator. However, this is a special case since the same variable 
appears on both sides). We also know that the ‘+’ operator returns a value 
of type Int (the arithmetic sum of the left and right hand sides), so we have 


the constraint 17 ~ Int. Altogether, we have the following constraints: 
C = {t1 ~ (To > 72), To ~ Int, 72 ~ Int} 


To solve these, we can substitute the type Int for T and 72 to satisfy 
all constraints. Since x : To and f : T1, we can infer that x : Int and 
f : Int — Int. 


A constraint-based inference algorithm is one which can be employed to 
generate constraints in this manner and perform unification to infer types 
(Krishnamurthi, Lerner, and Politz). An example is the Damas-Hindley- 
Milner algorithm (Damas; Hindley; Milner), which forms the basis of most 
inference algorithms used in statically typed FP languages. One important 
characteristic of Damas-Hindley-Milner inference is its completeness - it 
can infer the types of all terms within a given program, without any anno- 
tations or hints. This is known as global or full type inference, as opposed 


to partial type inference which can only infer the types of some terms. The 
other notable characteristic of Damas-Hindley-Milner inference is that it 
infers the principal type, that is, the most general type that encompasses 
all possible types for a given expression. Both properties are considered 
desirable in any type system. 


3 Features of Object-Oriented Programming 


One feature common to many OOP languages (such as Java, Scala, Type- 
Script, Kotlin, etc.) is polymorphism. Polymorphism is commonly defined 
as types (or entities) whose operations are applicable to values of more 
than one type (Cardelli and Wegner). Interestingly, this definition is broad 
enough to include most of the distinguishing features of typed OOP lan- 
guages, such as generic programming, subtyping and operator/function 


overloading, as we will see later. 


This definition, however, is too broad. Polymorphism can be further di- 
vided into different forms with more precise definitions, allowing us to 
better understand how they may act as barriers to type inference. In par- 
ticular, three forms of polymorphism are discussed: parametric, subtype 


and ad-hoc polymorphism. 
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4 Parametric Polymorphism 


4.1 System F 


Parametric polymorphism is when a data type, such as a function, can be 
written generically such that it can handle values independent of their type 
(Pierce). Such types are also known as generic data types. The following 


is an example of parametric polymorphism in Java: 


Listing 3: Generic Programming in Java 


public <T> ArrayList<T> wrap(T value) { 
ArrayList<T> list = new ArrayList<T>(); 
list.add(value) ; 


return list; 


This function simply wraps a value of type T into an ArrayList and re- 
turns the list. Note that the ArrayList data structure is itself a generic 
data type. This demonstrates the expressiveness and power of parametric 
polymorphism: functions no longer need to be bound by any one specific 


type. Rather, they can be expressed for any type T. We call T a type variable. 


STLC can be extended to support parametric polymorphism. STLC with 
parametric polymorphism is also known as System F (Girard; Reynolds). 
We have seen in the example above that parametric polymorphism is sim- 
ply the introduction of a special variable that ranges over types instead of 
terms. Thus, the formulation of System F can be achieved by introducing 
a new form of abstraction that takes a type variable as its argument, and 
returns a concrete type formed using that variable. A complete under- 
standing of System F is not necessary to understand the following section 
(although for completeness, the formal syntax and rules can be found in 


Appendix B). 
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4.2 Type Inference in System F 


The concepts of reducibility and undecidability are important to under- 
stand why type inference is difficult (in fact, impossible) in System F. A 
problem A is reducible to B if there is a way to convert any given instance 
of A to an instance of B. A problem is undecidable if there is no general 
algorithm to determine the answer for a given instance of the problem. 
Furthermore, if A is reducible to B, and B is undecidable, then A is also 
undecidable (Hopcroft, Motwani, and Ullman). 


It has been proven that, in System F, the problem of type inference is unde- 
cidable. This was proven by Wells by showing that type inference in System 
F can be reduced to another problem known as the semi-unification prob- 
lem, which had already been proven to be undecidable (Kfoury, Tiuryn, 
and Urzyczyn). While the proof itself is beyond the scope of this essay, 
this reduction implies that global type inference is not possible in a type 
system that supports parametric polymorphism. Not only that, it has also 
been shown that in many cases, even partial type inference is undecidable 
for System F (Boehm, “Partial polymorphic type inference is undecidable”; 


“Type Inference in the Presence of Type Abstraction”). 


Given the benefits and expressiveness of parametric polymorphism, most 
typed OOP languages choose to give up on global type inference in favor 
of this feature. Other languages, such as Haskell, allow a restricted form 


of parametric polymorphism where type inference is still possible (Pierce). 
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5 Subtype Polymorphism 


5.1 Subtyping 


Subtyping is a major characteristic of the OOP paradigm. Like parametric 
polymorphism, it allows writing code in a more abstract manner. For 


example, consider the following Java program: 


Listing 4: Subtyping in Java 


public class Main { 
public static void main(String[] args) { 
byte x = 100; 
short y = 1000; 
int result = add(x, y); 
System.out.println(result); // outputs 1100 


public static int add(int x, int y) { 


return x + y; 


Although the method add is defined for two parameters of type int, it 
works for byte and short as well. This is because byte and short are both 
subtypes of the supertype int. This means that both byte and short (and all 
other subtypes of int) can be substituted for int without compromising 
on the correctness of the program. This particular subtyping relation is 
commonly known as the Liskov substitution principle (Liskov and Wing), 
and is an important design principle of OOP. More generally, a type S is 
a subtype of some type T if any term of S can safely be used in a context 


where a term of T is expected (Pierce). 
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5.2 Record Types 


Subtype polymorphism is specifically important in OOP because of how 
it affects the way objects and object types behave. Commonly, an object 
is a “data structure encapsulating some internal state and offering access 
to this state to clients via a collection of methods” (Pierce 228). To better 
understand subtype polymorphism through the STLC under this context, 
we first need to extend it with a datatype similar to these objects. To do so, 
we will add the record type to the STLC. Records are simply a collection 
of terms identified by some label. Although proper object types in more 
complete programming languages are more complex and nuanced than 
this, it is sufficient for our purposes. 


First, the syntax for record literals and accessing fields of a record (projec- 


tion): 
Eni terms: 
(previous terms) 
| {l;=t; el} record 
| t.1 projection 
Vos values: 
f (previous values) 
| {1;=v; El} record value 
Tits types: 


re (previous types) 
¡damn record type 


The notation {1;=t;! € !-"} is used for a record with n fields, each uniquely 
labeled. The remaining grammar is straightforward. An example of a 
record using this syntax would be {x=true, y=false}. Relevant evalua- 


tion rules can be found in Appendix C. 
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The relevant typing rules for records are as follows: 


foreachi T+ ti: 7; Thti: {liri en) 

RE, Po _———— == 
Tr (1¡=t/ 1-13 : {liri +14 Pr tilj a 
The rule T-Rcd tells us that a record {1,=t;' 1-7} where each term of a 
field t; has some type 7; will have the type {1;:7;! € !-"}. For example, the 
record {x=true, y=false} has two fields x and y of type Bool. The type 
of this record would then be {x:Bool, y:Bool}. The rule T-Proj simply 
tells us that the type of a projection will be the type of the corresponding 
field. 


For convenience, we will make use of let-syntax to bind terms to a name, 


like so: let id = Ax.x, and similarly type to bind types to a name. 


With the addition of records, the benefits of subtyping in STLC become 
more apparent. Consider the following function: 


let f = (Ar :{x:Bool}. r.x) 


The function f takes a record containing the field x : Bool and returns the 
value of that field. However, the following well-behaved term would be 
considered invalid under the typing rules for function application (see rule 
T-App in subsection 2.2): 


f {x:true, y:false} 


The above application fails because, according to our typing rules, the 
function f can only take terms of the type {x:Bool}, while in this case it 
is being applied to the type {x:Bool, y:Bool}. Clearly, the term is well- 
behaved, because it only requires the argument to have a field x of type 
Bool. To overcome this, we introduce subtyping in the lambda calculus. 
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5.3 Rule of Subsumption 


Although there is much more to the formalization of subtyping in lambda 
calculi, in our case we only focus on the aspects relevant to our discussion, 
namely the subsumption rule. We will assume that a record type S is 
a subtype of some other record type T if it contains at least all the fields 
contained in T. This is denoted as S <: T. Then, we can add the rule of 
subsumption: 


Prt:s 
S<: T 
Trt:T 


T-Sub: 


This rule simply tells us that a term of some subtype S also belongs to its 
supertype T. For example, {x: true, y:false} belongs to both {x:Bool, 
y:Bool} and {x:Bool}, because {x:Bool, y:Bool} <: {x:Bool}. This 
solves the problem encountered in the previous section, because now the 
function f can accept not only the type {x:Bool}, but also all of its subtypes. 


5.4 Inference under Subtyping 


A closer look at the subsumption rule also gives us an idea of why inference 
may be problematic under the presence of subtyping: the term t now 
belongs to not just the type S, but also all subtypes of S. In other words, 


the same term belongs to multiple types. 


Let us consider the function f defined earlier, but this time without any 


type annotations: 
let f = (Ar.r.x) 


Now, due to the rule of subsumption, the variable r could belong to any 


of an infinite number of types. Given this program, without any type 
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annotations from the programmer, the most we can infer is that f is a 
function type that takes some record type as its argument, which contains 
a field x. Needless to say, this is not very practical or useful. 


The kind of subtyping discussed so far falls largely under the notion of 
structural subtyping, where the subtype relation between two types is based 
entirely on their structure (for example, the type and number of fields in 
two record types). A different notion is that of nominal subtyping, where a 
subtype relation may only exist if the programmer explicitly declares one 
so (Pierce). This is a common feature in many mainstram OOP languages, 
and usually includes special syntax as well, for example the implements 
keyword in Java. Under nominal subtyping, inference becomes even more 


difficult. Consider the following example: 


type A = {x:Bool} 
type B = {x:Bool} 
let f = (Ar.r.x) 


In this example, even though the types A and B are identical, they are 
seen as entirely different types under nominal subtyping, because we did 
not declare any subtype relation between them. Thus, even if we were 
able to infer that r is of type {x:Bool}, it would be impossible to deter- 
mine whether it is of type A or B without explicit annotations from the 


programmer. 
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6 Ad-Hoc Polymorphism 


Ad-Hoc polymorphism allows overloading of functions and operators to 
different types (Pierce). A common example would be overloading the ‘+’ 
operator to work on both integers (as an arithmetic operator) as well as 


String types (as a concatenation operator). 


The issues this poses to type inference are straightforward. Consider the 


function from Listing 2: 


fx =X+*X 


Assuming the ‘+’ operator is overloaded for both integers and Strings, both 


of the following lines are valid: 


f1//==2 
£ “ha” // == “hihi” 


The function f can be applied to both integers and strings. In other 
words, the variable x can now belong to two different types depending on 
the argument provided. This is similar to the problem faced with subtype 


polymorphism, making type inference difficult. 


Ad-hoc polymorphism is another feature popular with OOP languages, 
but can also be found in some strongly typed functional programming 
languages, such as Haskell. These languages introduce more complex 
constructs such as typeclasses (O'Sullivan, Stewart, and Goerzen) that al- 
low overloading of functions without sacrificing type inference. However, 
typeclasses are not very suitable for type systems supporting the OOP 
paradigm. 
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7 Alternative Techniques 


Despite these challenges, there are several techniques for performing (par- 
tial) type inference in OOP languages. One increasingly common tech- 
nique is local type inference (Pierce and Turner). Compared to the full type 
inference of Damas-Hindley-Milner, local type inference is very much lim- 
ited. This technique recovers type information from adjacent nodes of the 
abstract syntax tree (the internal representation of a program, as a tree 
structure) after the parsing stage of the compiler (Pierce), when possible. 
This allows it to perform simple inferences, such as in variable declarations. 
Numerous modern OOP languages, such as Java, Scala, Visual Basic, C# 
etc. use a form of local type inference. For example, Java introduced the 
var keyword which enables local type inference in variable declarations, 


so that code such as the following: 


HashMap<String, String> map = new HashMap<String, String>(); 


Can be shortened to: 


var map = new HashMap<String, String>(); 


In such cases, the inference engine can observe the type of the expression 
on the right-hand side of the assignment operator (provided the expres- 
sion is simple enough) and assign it to the variable on the left-hand side, 
without requiring any annotations for it. Even though local type inference 
lacks completeness and the principal type property, it can still provide 


surprisingly sufficient inference in many cases, and reduce verbosity. 


Aside from this, other more powerful techniques have also been developed. 
For example, bidirectional type inference (Pierce and Turner), implemented in 
the Swift programming language (Suter). In this technique, type informa- 
tion is propagated further in both the backwards and forwards direction 
from the nodes of a syntax tree, allowing for more powerful type inference. 
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Algebraic subtyping (Dolan) is another powerful type inference technique 
that allows inference under the presence of subtyping. Although type in- 
ference for simple subtypes had been possible to some extent (Mitchell), 
algebraic subtyping is notable in that it extends Damas-Hindley-Milner in- 
ference to provide full support for subtyping, while retaining the principal 
type property (Parreaux). 


Although a detailed discussion of these techniques is beyond the scope 
of this essay, they highlight the possibilities of type inference in OOP 
languages. 
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8 Conclusion 


In conclusion, global type inference for statically typed OOP languages 
supporting parametric polymorphism is not possible, while global type 
inference for OOP languages supporting ad-hoc or subtype polymorphism 
is possible but complex. However, simple partial type inference for typed 
polymorphic OOP languages is still possible to a large extent, through 
techniques such as local type inference and its variants. In most cases, this 


partial type inference is sufficient to a large degree. 


In fact, it is important to note that while type inference has many bene- 
fits in terms of programming language design, there are also cases where 
(global) type inference may not be desirable. Even in languages that do 
support global type inference, it is often discouraged in practical settings. 
This is due to the fact that type annotations can also serve the purpose of 
documenting code, and making it easier to understand. Moreover, type 
annotations also aid the compiler in analyzing the code and providing 
more useful and readable error messages (as opposed to error messages 
containing obscure type variables that are not very helpful to the program- 
mer) (Pierce and Turner). In these cases, type annotations are encouraged, 
while type inference is relied upon only when code becomes verbose or 
unreadable. This situation is ideal for partial type inference techniques, 
making them quite useful and practical. 
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9 Appendices 


9.1 Appendix A: Notation 
Backus-Naur Form 


BNF is a commonly used notation for expressing the syntax of program- 
ming languages (called a grammar). Essentially, it is a set of rules that can 
be used to generate strings that follow the syntax defined by the grammar 


(or in other words, syntactically valid strings) (Nystrom). BNF consists of: 


e Terminal symbols, which are literal values of the string generated. 


e Non-terminal symbols, which are used to reference other rules of the 


grammar. 


e Productions, which are the rules themselves. Each production is of 
the form LHS ::= RHS;, where the LHS is anon-terminal symbol, and 


the RHS is a sequence of either terminal or non-terminal symbols. 


For example, the following could be a BNF grammar defining the signature 
for methods in a Java-like programming language: 


Sig ::= Visibility Access Type Name ‘(’ Params ‘);’ ; 
Visibility ::= ‘public’ | ‘protected’ | ‘private’ ; 
Access ::= ‘static’ | ‘’ ; 
Type ::= ‘boolean’ | ‘byte’ | ‘char’ | ‘int’ | ‘float’ ; 
Name ::= ‘A’ |... | ZP? | fa’ |... | ‘z? | Name ; 
Params ::= Name | Name ‘,’ Params ; 


The pipe symbol (‘|’), read as ‘or’, separates the sequences of a production. 
We are allowed to choose whichever we want. Terminal symbols are 


enclosed within quotes to differentiate them from non-terminal symbols. 
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Note that this change is for simplicity only; in the grammar for A-calculus 
(and use of this notation elsewhere in this essay), quotes do not enclose 


non-terminal symbols. 


To generate a string from this grammar, we start from the rule Sig. It 
tells us to go to the rule Visibility, which has three non-terminals. We 
choose, for example, the first one, ‘public’. Now our string is: public 
Access Type Name ‘(’ Params ‘);’. We then look at Access, which 
is either ‘static’ or the empty string. Choosing the first one again, we 
have: public static Type Name ‘(’ Params ‘);’. Similarly for Type, 
if we choose ‘boolean’, we then have: public static boolean Name ‘(’ 
Params ‘);’. For Name, notice that it contains the entire english alphabet, 
and then recursively references itself. This allows us to generate any se- 
quence of letters to form a name. We can choose, say, ‘isEqual’. We thus 
have: public static boolean isEqual ‘(’ Params ‘);’. For Params, 
we can have either one Name, or a recursively generated sequence of Names 
separated by a comma, for example ‘a, b’. We then have: public static 
boolean isEqual ‘(’ a, b ‘);’. Putting it together, we get: public 
static boolean isEqual(a, b);. 


Inference Rules 


In logic, inference rules are a form of syntactic expressions which take a 
number of premises, written above a horizontal bar, and return a conclusion 
based on those premises (Suidman, “Introduction to Type Systems: Simply 
Typed Lambda Calculus”). The prime example is the modus ponens, which 
takes two premises, p and p => q (if p then q), to return the conclusion, 
q: 

P 

Pp = q 
q 


modus ponens: 
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This rule can be read as “given p and p => q,then we can conclude q”. If 
there are no premises given above the horizontal bar, then the conclusion 
under the bar is considered an axiom, that is, it is considered to always 
hold. 


Turnstile 


The turnstile (‘+’) is also a feature from a logic system (namely sequent 
calculus) which is used to separate assumptions (appearing on the left) 
from propositions (appearing on the right). It means that the proposition 
on the right can be derived or deduced from the assumptions on the left. 
The symbol + can be read as ‘yields’ or ‘entails’. Multiple assumptions may 
appear on the left side, but only one proposition can appear on the right 
(Kleene). As an example: p,p => q+qreads‘pandp => q yields g’, 


which is valid since q can be directly derived from the assumptions. 


Typing Context 


A typing context, usually denoted T, is a set containing the declarations of 
variables and their types. For example, IT = {x : Int, f : Int — Bool} is an 


example of a typing context (Pierce). 


Typing Judgments and Typing Rules 


A typing judgment is essentially an assertion telling us the type of an 
expression once it is fully evaluated (Pierce). For example, 1 + 1 : Int isa 
typing judgment telling us that the expression 1 + 1, once evaluated, has 
the type Int. 


However, we often come across expressions such as x + 1, where we have 


a variable whose type we do not know. These expressions have to be 
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considered with respect to some typing context which can tell us the types 


of the variables appearing in it. 


We can define the following inference rule to say that if the variable x and 
its type T is in the context, then we are allowed to conclude that in an 


expression containing the variable x, the type of x is T: 


x:Ttelr 
Trx:7T 


Inference rules such as this which combine typing judgments are com- 
monly referred to as typing rules. 


Going back to our example of the expression x + 1, if we have the context 
T = {x : Int}, then we can assert the type of x + 1 with the judgment 
I+ x +1: Int, since T now contains the type of x. 


In this manner, by combining typing judgments with the turnstile notation, 
we can write the judgment l'E e : 7 to say that, under the assumption that 
T contains the types of all variables occurring in e, we can assert that e, 


once evaluated, has the type type 7. 


9.2 Appendix B: System F Rules 


To extend A-calculus with polymorphism, we make two new additions: 
type variables, which are similar to normal variables except that they 
range over all types rather than values, and polymorphic types, which are 
types that contain type variables (Serensen and Urzyczyin). 
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These additions require new syntax for types: 


Tits types: 
X type variable 
| VX.T polymorphic type 
| T> T function type 
| Bool boolean type 


Listing 3 already gives an example of a type variable. An example of 
a polymorphic type would be VX.X — X. A function with such a type 
would accept a value of any type, and return a value of the same type 
(this is similar in nature to the identity function - in fact, it turns out that 
any function with the type VX.X — X will be equivalent to the identity 


function!). 


We also update the syntax for terms in order to allow type abstraction and 


application: 

t iis terms: 
ss (previous terms) 
| AX.t type abstraction 
| tT type application 


Type abstractions are again similar to normal abstractions, but with type 
variables instead of normal variables - the term AX.t introduces a new 
type variable X, abstracted over the term t (similar to the type variable T 
abstracted over the method wrap in Listing 3). We can now write a generic 
identity function using type abstractions: 


let id = AX.Ax :X.x 


This is equivalent to the following Java program: 
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Listing 5: Generic Identity Function in Java 


public <T> T identity(T x) { 


return x; 


This type abstraction can then be applied to instantiate the polymorphic 
type with a concrete type. For example, ‘id Int’ applies the type Int to 
our generic id function. The type variable is then replaced with the specific 
type, in this case giving us id : Int — Int. In Java, this is analogous 


to supplying our generic method with a specific type when calling it: 


Listing 6: Generic Identity Function in Java 


identity<int>(1); // The type variable T is replaced with ‘int’. 


The typing rules for type abstraction and application are as follows: 


a PEt. er Tet: VX.t 
TIOS TE AXE: VAT RS Trtr:[xbo7]7 
The first rule describes type abstraction: AX.t has type VX.7 if t has type T. 
The second describes type application: if a term t has the type YX. t, then 
the type application t t’ has the type [X > 7']7, that is, the type obtained 


when 7’ is substituted for the type variable X. 


These rules form the basis of System F, and outline how it is equivalent to 


generic programming patterns in mainstream programming languages. 
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9.3 Appendix C: Subtyping for Record Types 
Evaluation Rules for Records 


The relevant evaluation rules for records are as follows: 


E-Proj: E E-ProjRcd: {lj=v;' € TI .lj — vj 
tb t’1.l1 
E-Proj tells us to fully evaluate a record term before applying projection, 
while E-ProjRcd tells us that a projection of some label 1; on a record 
evaluates to the corresponding value v; of the field identified by the label. 
For example, {x:true}.x evaluates to true. 


Basic Subtyping Rules 


The following transitivity and reflexivity rules can be derived straightfor- 
wardly from the Liskov substitution principle (that a supertype may be 
safely substituted with its subtype in any context): 


S-Trans: ¿o ee S-Refl: S <: S 
S<: U 
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